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"Method and System for simulating communications 
networks, object and computer program product therefor" 

5 Field of the invention 

The- present. ' invention refers to techniques for 
simulating communications networks such as, for 
instance/ radio-mobile cellular networks. . 

. The simulation.' is an essential step in planning, 
10 designing,* realizing and managing such networks, 
especially in view of the optimisation of performances 
of . the networks themselves. Particularly/ the 
simulation plays, an important role both at check level 
for planning a , new netwprk, -and at updating and 
15 optimising. : level . for performances of an already 
operating network.. 

The invention has been devised paying particular 
care to the techniques of survey of inherent statistic 
data tp the behaviour* o£ the simulated network. Typical 

20 examples of statistic data that can, be measured in a 

*» » 

radio-mobile cellular network system simulator are 
network capacity, mean, delay on packet transfer, 
percentage of blocked calls, etc. 
Description of tfie prior art 

25 It is known- that there .are cellular radio-mobile 

network system simulators characterised by an. object 
architecture,' such as disclosed, for. example, in* WO-A- 
02/104055. According to the object " approach, the 
elementary decomposition unit is not the operation 

30 (method), but the object, v meant as model of a real 
entity (a real -world *obj ect) . 

It is known that^ in such simulators there are 
modules or devices adapted to simulate th£ behaviour of 
physical network devices. Every module or device can 

•35 have many .implementations ; (.according lo simulated 



WO 2005/051023 



2 



PCTYIT2003/000761 



functionalities or. technologies) and each of these 
implementations can be used at will in the simulations: 
a* different .way of .operating of the module in itself 
corresponds .to each implementation. It is also known 
5 that the modules' or devices in : the simulator mutually- 
exchange information',, with the purpose of simulating 
the behaviour - of real . physical network devices; the 
exchange of information occurs through two modes: with 
"messages" arid with 11 events". . ' * 

10 The communication with messages is characterized 

in that the receipt* of information by the target module 
occurs simultaneously with. the dispatch from the source 
module; instead, * the* communication with events is 
characterized in tlja.t the receipt of information from 

15 the target module does not occur simultaneously with 
the transmission from the source module, but in a 
particular .following /-.time, instant • after the 
transmission . time : the. use. of K the events serves for 
timing the receipt of a piece of information from the 

20 receiving module. 

It is also known, that these simulators are able to 
perform measurements * of / the "behaviour of the various 
simulated modules or devices, . providing some statistics 
related to these measurements as simulation results. 

25 In the arrangement described in WO-A-02/104055 the 

. objects-simuiator / "architecture . provides an engine in 
which there is an entity called .Statistic Manager. Task 
of such entity ~is performing, by intercepting 
communications between . module and module, the 

30 measurements related- ' -to the behaviour of modules or 
devices themselves and processing statistics of 

measured statistic data. 

.* 

A typical example of statistic processing is the 
*• computation of mean*, transmission delays of a. packet. In 
35 this -case, the Statistic Manager entity " performs, for 
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every packet transmitted <in the simulated system, a 
delay measurement, averaging among them the various 
measured delays, obtaining the mean delay as result. 

I-t is Tcnown that - with analogous operating 
5 criteria - all interesting statistic 1 processing in a 
system simulator can be realised, for instance for 
radio-mobile cellular networks. 

The Applicant has- observed that in a situation of 
the previously described, type, various types of 
10 problems occur, that are . intrinsically tied up to the 
possible and _ frequent presence -of different 
• implementations of the same .network 'functionality! 

Firstly, the communication among two modules 
occurs directly through the ; irespective implementations: 
15 in every -implementation of a given module^ it * is 
therefore necessary; ^ to insert, • for - the Statistic 
Manager's benefit/ all information that identify 
communication modes ' with ail implementations of the 
other modules with which the affected module can 
20 communicate.. ' . . 

Secondly^ the. mechanism with which the Statistic 
Manager measures the -'behaviour of the modules or 
, devices changes according to implementation, because it 
has to suit itself for *th§~ particular module/device 
25 implementation. 

Insofar, depending on : known prior art, with the 
purpose to be able to take into account the presence of 
many implementations of the same device or module, it 
is necessary • to insert in • the Statistic Manager a 
'30 specific interception' 'and * measuring mechanism, 
operation that can be also very costly in terms of time 
and processing complexity . 

It will also be appreciated that this is worth 
above • all for the telecommunications networks (where 
35 the same network functionality is performed by 
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apparatuses supplied by different manufacturers, with 
different implementations) and that the same type of 
problems occurs, in substantially identical terms, also 
in the communication between various modules or 
5 devices, therefore, in . a way. that is independent from 
the intervention of the ."Statistic Manager or an- 
equivalent entity.- 

Object and, synthesis of the present invention 
Object ^ of the. present, invention - is therefore 
10 solving the above-mentioned problems. : 

According to the" present invention, such object is 
reached thanks to a methodr having the characteristics 
specifically .stated 'in the claims that follow. The 
invention also relates to the corresponding system 
15. (simulator) , "to the objects included in the same, as 
well as to a corresponding computer program product 
loadable in the memory of* at-, least one electronic 
computer and comprising portions of software code to 
perform th£ method according to the invention when the 
20 product is executed on a computer: in this context such 
term must be deemed entirely equivalent to means 
readable. by a computer comprising instructions to check 
a network of computers in order to perform the method 
according to the invention. The reference to "at least 
25 one electronic computer" is obviously aimed to show the 
possibility of performing the solution according to the 
invention in a *de- centralized context. 

In its currently 'preferred embodiment, the 
invention solves the . above r mentioned problems by 
30. introducing for the modules or devices in the simulator 
respective interfacing, objects .with the other modules. 
Such interfacing objects have an .'"external" side and an 
"internal" side with respect to 'module or device. Such 
external side . has • an independent character from the 
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idiosyncrasies of. said module or device and is 
therefore uniform for all system modules or devices. 

The term "uniform" obviously means such a 
character that the "external" side of said interfacing 
5 objects is independent frtpm the respective module or 
device, and can thereby be substantially identical for 
all modules or devices. ' 

The previously- mentioned problems, intrinsically 
linked *to the possible presence of different 

10 implementations of network functionality, are thereby 
solved, also as regards to the' possible, intervention of 
the Statistic Manager or an 'equivalent entity. 

In a particularly preferred way, the following 
interfacing' objects are introduced: 

15 - communication interfaces* among all simulated 

modules and/or devices: interfaces of this type manage 
the conimunication with* ".events" and with "messages" and 
make implementations . of single modules independent from 
the type of . communication that every module is able to 

20 perform with. other modules in the simulator. 
Particularly,, for every module/device there is a unique 
communication interface - for all : different 
implementations, of the' considered module; "every 
communication operation amon^f modules and/or devices 

25 occurs through the communication interfaces; 

- statistic interfaces of simulated modules- and/or 
devices: the interfaces of this type make statistic 
surveys performed by the Statistic Manager entity 
independent from the implementation of simulated 

30 modules from .which statistic data are. detected. 
Particularly, there is an . interfacing object for every 
single injplementation of the modules of interest; in 
this interfacing object, the measuring mechanism of 
..statistic data from the corresponding module is 

35 realised in a simple way. The Statistic Manager entity 
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collects the detected data through the external side, 
made uniform, of interfacing objects and more directly 
from single modules. 

Brief, description of the attached drawings 
5 The invention will be described, purely as a non- 

limiting example, with reference to the attached 
drawings, in which: ' m t 

- figure li is a functional approximate diagram of 
a simulator of the herein described type, 

10 - figure 1 2 shows. 1 - the architecture of related 

communication interfaces, 

- figures 3, 4 and 5 show a possible organization 
of messages and evferits withiii a .simulator of the herein 
described type, 

15 - figure 6 .is a functional approximate diagram of 

a statistics managing' module in a simulator of the 
herein described type, 

- figures 7 and 8 show in detail the architecture 
of the relative statistic interfaces, 

20 - figures 9 and 10 are exemplified flow diagrams 

of the operating modes of the herein described 
simulator, and 

- figure 3-1 synthetically shows the statistics 
operation wrthin a simulator of the herein described 

25 type . ■ * * 

Detailed description .of an embodiment, of the invention 
Figure' 1 shows the architecture of a simulator 10 

comprising an engine 11 iri which there are all typical 

managing functionalities of the simulation of a 
30 telecommunications network, . such as a radio-mobile 

network, namely: ' \ 

- Parameter Manager ,11a, 

- Event Scheduler lib, 

- .Factory Manager 11c, and 
35 - Statistic Manager, lid. 
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A device package 12 ' is then present in which the 
different devices 13 are contained, representative of 
the physical, network devices and the objects related to 
the scenario to 'simulate. 
5 ' Every device contains different modules 

related to the different functionalities managed by the 
device itself.' - ■ 

Such a simulator, working in general among a 
set of input signals I. ? and a set of output signals O, 
10 • can be implemented, for instance, on a computer with 
Intel Pentium III processor and Microsoft Windows 
operating system, .using Microsoft Visual Studio 6.0 
development environment and ANSI C++ v - programming 
language. 

15 . . As shown in figure* 2, every module 13 1 , 13 1 1 

present in the device package 12 can have many 
implementations" 13b 1 ., 13c 1 or : 13b 1 1 , 13c 1 13d 1 each 
one related' for instance to a set of simulated 
functionalities or to a specific technology. 

20 The herein described arrangement' has the chance of 

having, for all implementations of a module, a single 
communication. . interface 13aJ , lSa 11 ,.... that is used in 
the information exchange with other modules. 

The concept is general and can be applied to any 

25 module or device in a cellular network simulator. . 

Every , module has its own communication interface : 
interface 13a 1 for module 13 1 and interface 13a 1 1 for 
module 13 ' . 

Module 13 1 has two different implementations 13b 1 
30 and 13c 1 , and botii use interface 13a 1 to communicate 
with other modules, as for instance with module 13 1 1 . 

Module /13 1 1 has three different implementations 
13b 11 , 13c » ' and 13d' ' , and all use interface 13a 11 to 
communicate with the other modules, as for instance 
.35 with module 13 ' . 
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The use of interfaces in the communication among 
' modules allows making ' .the insertion of. new 
implementations of a module- simpler and quicker without 
having to manage from time to time the functionalities 
5 related to information exchange. 

Every communication- - interface (or "interfacing 
object") introduces in fact an "external" side A and an 
"internal" side «,B with respect to module or device 
13b 1 , 13c 1 ', or 13 b 1 13c 11 and 13d 1 1 . 
10 The internal side B rieflects the characteristics 

(or "idiosyncrasies") of the specific module or device 
and, more particularly, of the specific implementation 
considered every time. 

Cont;rarily/ x the* external side - A of every 
15 interfacing object 13a 1 , .13a 11 is uniform for all 
system modules or devices, and therefore for all 
possible j implement at ions of the same. 

The term "uniform" obviously means such character 
for which the external side A . of the interfacing 
20 objfectef is independent from the respective module or 
device,, and can thereby be substantially identical for 
all modules or devices. x 

Particularly, the \ external side A of the 
interfacing objects is configured in order to allow the 
25 information interchange between modules or devices with 
two modes : . 

- i) through "messages": .the information exchange 

occurs through the use of objects called "messages". 

» 

Depending on the structure shown in figure 3, 
30 every "Message" 100 is characterised by an indicator of 
. the source or sender module or device S, by an 
indicator of the target module or device "Target" 110 
and by the information exchanged among modules "Data" 
120. The communication with messages is characterized 
35 in that the receipt of information from the target 
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module occurs simultaneously with the transmission from 
the source module . 

- ii) through "events": the information exchange 
occurs through the .use o£ objects called 'levents". 
5 Depending - on the structure shown in figure 4, every 
"Event" 200. is characterised by an indicator of • the 
source or sender module- or device, S, by a "Time" 210, 
by an indicator of the target module or device "Target" 
22 0 and by information exchanged among modules "Data" 

10 230. The communication With , events is * characterized in 
that the receipt of information from the target module 
does not occur simultaneously with the transmission 
from the source module, but in a particular time 
instant following the transmission time. 

15 The use of events serves .for "delaying" the 

receipt of , an information from the receiving module. 
The communication with events occurs through the entity 
called- Event Scheduler . that can be found in the 
simulator engine; function of the Event Scheduler is 

20 storing events, and relative time in a queue, called 
"queue of events", and sending every event to its own 
target module when the simulation time reaches the 
event time itself- ■ 

The implementation of every communication 

25 interface provides for four* main functionalities, you 
respectively called: ■ 

MessageDispatcher <MessageType> : dispatching 
functionality- .of .messages -of the . MessageType type, 
where MessageType represents any type of message; 

30 - Event Dispatcher <EventType>: dispatching 

.functionality of events of the EventType type, where 
EventType represents any type of event; 

MessageListener <MfessageType> : receiving 
functionality of messages of 'the* MessageType type, 

35 where MessageType represents any type of message; and . 
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EventListener / <EventType> : receiving 
functionality <of events of the. Event Type type, where 
Event Type represents any type of event . 

Every dispatching or receiving f unctionality of 
5 messages/events can be found or hot in * the 
cqmrnunicatioh interfaces. 

It is possible to have ' interfaces with only a 
subset of possible functionalities, for instance an 
interface can be . only MessageListener of a message 
10 . without* necessarily: having the other three 
functionalities. 

Besides, in a single ' interface, the same 
functionality can be presefnt many times, in order to 
manage different messages/events. For- example, an 
15 interface that has to be able to receive two types of, 
different events has two EventListener functionalities: 
one for the first type, of event and another for the 
second type of event . 

As further example (not to be meant as; limiting of 
20 the scope of the invention) what is shown in -figure 5 
can be taken into account., . 

Here there are types . of events ".Event A" 1000, 
"Event ^B" 1010 and ' "Event C" 1020, the types of 
messages "Message 1" 2000 and ."Message 2" 2010 and the 
25 interface related to module "Module ABC" 3 000 that it 
is able of: , , 

- receiving and sending events of the "Event A" 
type \ 

- receiving events of the "Event B" type 
30 . - sending events of the "Event C" type 

- receiving message "Message 1", and 
-sending message "Message 2" 

The related interface has the following 
functionalities active: • - 
.35 - EventListener <Event- A> 3 010 
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- Event Di spat cher <Event A> 302 0 

- EventListener <Event B> 303 0 

- EventDispatcher" <Event C> 3040 

- ' MessageListener <Message 1> 3050, and 
5 - MessageDispatcher <Message 2> 3060 

The realization of the simulator interfaces can 
advantageously be performed with C++ • programming 
language. 

Iri case of the above -described example we have the 
10 following code: 

class Event 

. { 

GenericEventDi spat cher. * source 
15 GenericEventListener * target 

Int timej 

} 

class EventA . 
: public Event 
20 { . 

} . " 

class EventB 
: public Event 
25 { 

} 

class Event C 
: public Event 
30 { 

} 



35 



class Message 

{ • 

GenericMessageDispatcher * source 
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GenericMessageListener * target 

} 

class Messagel 
5 : public Message * 

{ . 
} 

class Message2 
10 : public Message 

{ 

> . ■ ■ 

class ModuloABC__Interf ace 
15 :. public EventListener <EventA> 

public Event Dispatcher <EventA>' 

, public EventListener <EvfentB> 

, public Eventbispatcher > <EventC> 

, public MessageListener <Messagel> 
20 , public Messagebispatcher <Message2> 

{ 
} 

class' ModuloABC 
25 : public ModuloABC_Interf ace 

[.-.] 
{ 

[....] .ABC module implementation 

} ; • 

30 . The use of simulator interfaces also involves the 

architecture related to. Statistic Manager. 

In the simulator, statistic processing is the task 
of the Statistic Manager lid entity that can be found 
in the engine (see figures 1 and 6) .* 
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The 'Statistic Manager .lid contains the objects 
that store the various statistics, called "Statistic 
Calculators" . . * 

Figure 6 shows as an example three entities SCI, 
5 SC2 and SC3, every . one operating"' as statistic 
calculator related to. the processing^ of- a particular 
statistic quantity: ,SC1 can . for instance be related- to 
. system capacity, SC2 related to mean transmission 
•throughput of the packets, SC3 related to the level of 
10 power used in transmission by the simulated radio- 
mobile terminal . 

The operation .of the affected computers is 
independent from the implementations of the simulated 
modules and is only function of the types of statistic 
15 samples to analyse . 

The herein described .arrangement provides that, 
for - every implementation of a . module, an adequate 
statistic .interface is realized, referenced by the name 
"Data Collector", whose aim is collecting the statistic 
20 samples of interest - from the corresponding 
implementation and sending them to the Statistic 
Manager entity, that proceeds then to their processing. 

As a non-limiting example, figure 7 can be taken 
into account, where there is a device 120 in which two 
25 modules 121.' ^nd 123 are present- - 

Module 121 has two different implementations 121a 
and * 122a. 

For every implementation, there is a statistic 
interface* (Data Collector) : implementation 121a 
30 corresponds to statistic interface • 121b, implementation 
122a corresponds to statistic interface 122b. 

Module 123. .has . three . different implementations 
123a, 124a and 125a. 

For every implementation there is a statistic 
35 interface (Data Collector) : implementation 123a 
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corresponds to statistic interface 123b, implementation 
124a corresponds . to statistic interface 124b, 
implementation 125a corresponds to statistic, interface 
125b. 

5 Also in this case, every communication interface 

'or interfacing object has in fact an external side A 
and an internal side B with respect to module or device 
121a, 122a or 123a, 124a and 125a. ; 

The internal side B reflects the characteristics 
10 or idiosyncrasies of the specific module or device and, 
more . particularly, of the specific implementation 
considered every time. 

Contrarily, the . external side A of every 
interfacing object 121b, 122b or 123b, 124b, 125b is 
15 uniform for all system modules, or devices and therefore 
for all possible implementations of the same . - 

The external side A of the interfacing objects is 
therefore independent from the respective module or 
device, and can thereby "be substantially identical for 
20 all modules or devices. t 

As an explanation and example, it can be supposed 
that module 121 ' manages the transmission of a packet; 
in this case a statistic sample of interest is the time 
employed to transmit every single packet. Therefore, 
25 every 4 statistic interface 121b .and 122b of the 
different implementations of module 121a and 121b must 
be able to identify arid*; collect the time used to 
transmit a packet from the corresponding implementation 
of module 121. 

30 In general, the two mentioned implementations of 

*nodule 121a arid 122a totally' manage the transmission of 
a packet • in different way, therefore the two 
corresponding statistic interfaces 121b and 122b have 
to measure the time of transmission of a packet with a 

35 different mechanism. 
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The implementation of every statistic interface 
preferably provides for a functionality DataDiispatcher 
<DataType>, namely a dispatching functionality of 
statistic data of the DataType type, where DataType 
5 represents any statistic data type. 

As further non- limiting example, what is shown in 
figure 8 can be taken into account, where in the left 
part there are the types of statistic data "Data A" 
1100, "Data B» 11*01 and "Data C» 1102, and in the right 
10 part there are the statistic interfaces related to 
module "Module 1" 1300 and to module "Module 2" 1301. 

The interface related to module "Module 1" 13 0 0 
. are able to send statistic data of the "Data A" 1100 
type and of the "Data C" 1102 type. 
15 The interface related., to module "Module 2" 1301 

are able to send statistic data of the "Data B" 1100 
type and of the "Data C" 1102 type. 

Then the interface related to module "Module 1" 
1300 has the following .functionalities active: 
20 - DataDispatcher <Data A> 13 00a 

- DataDispatcher <Data C> 1300b. 

The interface related to mpdule "Module 2" 301 has 
the ' following functionalities active: 

- DataDispatcher <Data.B> 1301a 
25 - DataDispatcher <Data C> 13 01b - 

The realization of statistic interfaces in the 
simulator ' is preferably performed with programming 
language C++. 

In case of the • above -described example, we have 
30 the following code: 
class DataA 

" { 

[. . .] 

} - . 

35 
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class DataB 

{ 

[....] • 
} 

class DataC 

{ 

[. . .] 
} 



' class Modulol_StatisticInterf ace 
: public DataDispatcher <DataA> 
, public DataDispatcher <DataC> 

{ 

15 } 

class Modulo2_StatisticInterf ace 
: public DataDispatcher <DataB> 
, ' public DataDispiatcheir. <DataC> 
20 { 

The operation of dispatching a message is shown in 
figure 9 and is described as follows: 

' . . - step 1001: the implementation of sender module 
25 sends the message to its own interface MessageType; 

- step 1002: the interface t of sender module sends 
the message MessageType to the interface of the 
receiving module; ' % 

- step 1003: the interface of the receiving module 
30 receives * the message MessageType and sends it to the 

implementation of the module. 

The operation of dispatching an event is shown 
instead in figure 10 and is described as follows: 
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step 2001: the implementation of the sender 
module sends the event to its own interface EventType, 
pointing out the time of receipt t; 

- step 2002: the .interface of the sender module 
5 sends Event Scheduler to the entity, the event 

EventType pointing out the time' of receipt t; 

-step 2003: when the simulation reaches the time 

t, the entity Event Scheduler sends the event ' EventType 

to the interface of the target module; 
10' - step 2004: the interface of the receiving module 

receives the event EventType and sends it to the 

implementation, of the module. 

The- general operation of the method for collecting 

statistic samples, in a given simulator is shown in 
15 figure 11/ where as an example the Statistic Manager 31 

manages three statistics (Statistic Calculator) 31a, 

31b and 31c. Statistic 31a processes samples type K, 

that obtains from .a first module having two 

implementations 32a and 33a, which respectively 
20 correspond to statistic interfaces 32b and 33b. 

The collection of statistic samples occurs as 

described as follows: :■ 

- during simulation/ statistic interfaces 32b and 
33b identify samples type K, each one with a proper 

25 mechanism that takes into .account the functionalities 
of the corresponding implementations 32a and 33a; 

- at every simulation step, the Statistic Manager 
queries the statistic interfaces so that they send 
directly Collected samples type K to statistic 31a; and 

30 - with a suitable interval, statistic 31a 

processes samples type K and sends forth 'the result. 

The herein described arrangement essentially 
involves two>m^in advantages. 

Firstly, the communication mode between simulated 
35 modules and devices is independent from individual 
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implementations of modules/devices. In this way, the 
information exchange modes between modules and devices 
are established once and. for all defining the 
communication interfaces of every module and device. 
5 ' Every time it is decided to introduce in the simulator 
a new implementation for a device or for a module, it 
is not necessary to worry about the 'management of 
information exchange because this is already managed. 

Secondly, it is possible to rationalize the 

10 planning of statistics managed by the Statistic Manager 
entity since it does not depend from which 
implementations of devices or modules are used in the 
simulation. In ;this way, every time it is decided to 
introduce in the" simulator a new implementation for a 

15 device or for a module, it is enough to realize the 
corresponding* statistic • interface (Data Collector) , 
without having to modify the. operation of the Statistic 
Calculator. r 

As a result of the described situation, a flexible 

20 and slender general architecture of the simulator is 
obtained. 

As already said, the implementation of the 
described simulator can fcje realized with any type of 
computer, such as Intel, SUN, Apple, . . . and with any 

25 operating : system (Windows, Linux, Unix, MAC OS . . . ) . The 
use of ANSI C++ programming language is. only a possible 
choice; the implementation of the- simulator can be in 
fact also performed in other programming languages, 
such as Java, Delphi, Visual Basic, ... 

30 The choice of ANSI C++ language appears currently 

preferred in view of the good planning flexibility 
offered by said programming language and of the high 
level of obtainable performances in the finished 
program in terms of execution speed. 
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The invention can be used in cellular networks 
simulators that simulate other systems besides the 
mentioned GSM, GPRS .and UMTS . The invention can be used 
in cellular networks simulators that adopt the events 
5 simulation technique or the Montecarlo simulation 
technique. 

The skilled technicians in the art will 
immediately appreciate that the invention does not 
necessarily deal with the only simulation of radio- 

10 mobile cellular networks: the invention can in fact be 
also used in other types of simulators, where there is 
a similar . architecture with' modules and" devices 
complying with real physical equipment and where it is 
necessary to communicate among various modules/devices 

15 the parameters related to simulated functionalities. 

It is therefore evident tlp.at, notwithstanding the 
principle of the invention, the realisation particulars 
and the embodiments can be broadly changed with respect 
to what has been described and shown, without departing 

20 from the scope of the present invention, as defined by 
the attached claims . 



